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Description 



Method for reducing costs during the transfer of 
unidirectional information flows 

The invention relates to a method for reducing costs of 
5 processing useful data transferred in the direction of a 
communication device in cases in which a bidirectional 
connection between the communication device and a 
communication partner entity is set up within the framework of 
• a service, although the service does not require transmission 
10 of useful data to the communication device. 

The invention lies in the area of voice and data communication 
and in particular touches on aspects of switching technology. 

In communication technology there is constant striving for 
resource efficiency. In such cases making savings in 

15 communication devices for switching and distribution of useful 
data has an important role to play. When reducing the costs 
and the complexity of these types of devices however it should 
be considered that standards have to be complied with and the 
compatibility to other communication devices is to be 

20 preserved. These requirements frequently get in the way of 
reducing the means or resources used. 

An important example for communication devices with a 
potential for savings are devices of which the functionality 
does not demand any processing of incoming useful data. 
25 Examples of these types of communication devices are as 
follows : 

• Pure information output systems, e.g. pure voice response 
systems. For information output systems which only provide 
for the output of information (e.g. voice information) and 
30 may possibly not be able to be controlled by information 
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fed in from outside (such as systems for interactive voice 
response) the resources for processing of information 
transferred to the system can be reduced. 
• Pure distribution systems. Distribution systems are 
5 frequently restricted to the forwarding of or onwards 

transfer of information or useful data. Resources for the 
interpretation or processing of useful data can be provided 
to a reduced extent. 

The saving measures described above are restricted by the fact 
10 that there must be compatibility in communication with other 
devices or terminals. Thus there are communication entities 
(e.g. terminals, switching devices or gateways), for which 
bidirectional communication is provided within the framework 
of a communication process regardless of whether useful data 
15 is actually being sent to the communication partner entity. 
For connections for useful data transmission to this type of 
communication entity resources must be provided by information 
output systems or communication distribution systems for 
processing the information transferred by the communication 
20 partner entity, in order to make possible a bidirectional 
connection. 

An example for this type of scenario is the exchange of 
information between a pure voice response system and a 
terminal in which only a bidirectional connection is supported 

25 by the terminal. Although relevant information is only 

transferred in one direction (from the voice response system 
to the terminal) a transmission of useful data in the other 
direction also arises, which consists for example of the 
transmission of background noises picked up by a microphone of 

30 the terminal. The useful data flow or bearer flow transmitted 
from the terminal to the voice response system is then 
irrelevant for the seirvice but demands processing resources on 
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the voice response system side. 

In addition the protocols used for a bidirectional connection 
frequently provide for information to be sent in both 
directions which contains statistical data about the quality 
5 of the connection. This information is used for example to 
regulate the transmission rate. A communication device 
involved must thus have the means to generate this 
information. 

An important protocol in which the situation described above 
10 can occur is the RTF (real time protocol) which is used in 

connection with the RTCP (real time control protocol) . The RTP 
protocol makes it possible to transmit voice as useful data or 
bearer. The transmission of the bearer is controlled by the 
RTCP protocol. If for example a voice response system outputs 
15 voice information by means of the RTP/RTCP protocol stack to a 
terminal which only supports bidirectional RTP connections, 
statistical information about the connection is transferred in 
both directions by means of the RTCP protocol. 

The object of the invention is to make possible a reduction in 
20 costs for communication devices. 

The object is achieved by the objects of the independent 
claims . 

. The invention is based on the observation that for 
communication devices which in general or for specific 

25 services do not provide for transmission of useful data to a 

communication partner entity, in cases in which despite this a 
bidirectional connection to the partner entity is set up, for 
example because the communication partner entity only supports 
bidirectional connections with the protocol used, the cost of 

30 processing of the useful data transferred by the communication 
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partner entity can be reduced by discarding at least a part of 
this useful data transmitted by the communication partner 
entity in the direction of the communication device. 

Examples of devices or services for which as a rule useful 
5 data transmission is only provided in one direction, i.e. 

unidirectionally, are information output systems (e.g. voice 
response systems) and distribution systems or information 
output services {e.g. voice response services) and 
distribution services. The communication partner entity can 
10 for example take the form of a terminal or a gateway. 

The invention has the advantage of greater resource efficiency 
compared to conventional systems. The cost of processing is 
reduced by transmitted useful data which is irrelevant for the 
service being discarded. An irrelevant background noise which 

15 may possibly be transmitted for a voice connection is not 

completely evaluated in the communication device. Savings can 
be made in some of the hardware or software resources which 
are conventionally provided in the communication device for 
processing of useful data transmitted to the communication 

20 device This can involve expensive special hardware such as 
DSPs (DSP: digital signalling processor) or ASICs (ASIC: 
application specific integrated circuit) . 

The invention can for example be used in packet-oriented 
networks over which useful data is transmitted as useful data 
25 packets in the direction of the communication device. In this 
case the discarding of the packets can be implemented for 

example in the following two ways: 

• A router upstream from the communication device discards 
the useful data transmitted to the communication device. 
30 • Incoming data packets are filtered in the communication 

device, e.g. on the basis of the UDP port addresses (UDP: 
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user datagram protocol) , and useful data packets which were 
sent by the communication partner entity are discarded. 
This filtering out of the useful data not relevant for the 
service can be undertaken on the lower layers of the 
5 protocol stack. Processing on the upper layers of the 

communication protocol or an evaluation or interpretation 
of transferred useful data is not required, so that no 
resources have to be provided for this . 

The useful data packets are transmitted for example in the 

10 case of real-time traffic by means of the RTP protocol. The 
RTCP protocol is used for the control of RTP connections. In 
accordance with the RTCP protocol statistical information is 
transmitted between the commiinication entities which 
frequently relates to the transmission quality of the useful 

15 data transmission of the communication entities. 

Conventionally the generation of such statistical information 
or in general of control information on connection quality 
requires the transferred useful data to be evaluated. The 
present invention however provides for part of the useful data 

20 to be discarded in the cases discussed, that is not evaluated 
in relation to transmission quality. In accordance with an 
advantageous development the control partner entity can be 
prevented, on account of missing or misleading messages or 
information about the connection established to a 

25 communication device, from initiating undesired reactions - in 
the extreme case the ending of the bidirectional connection. 
In this case the communication device sends information or 
messages to the communication partner entity which simulate a 
correct functioning of the useful data transmission from the 

30 control partner entity to a communication device. In this case 
for example a known range of values for the control 
information can be used which corresponds to a trouble-free 
useful data transmission. Furthermore it is possible for a 
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small part of the useful data not to be discarded but to be 
evaluated for the calculation of statistical information or 
control information and for the results obtained to be 
extrapolated for the entire volume of useful data. 

5 The invention is explained in greater detail below within the 
context of an exemplary embodiment with reference to Figures. 
The Figures show: 

Figure 1: a communication device and a communication partner 
entity which communicate with one another, with 
10 useful data transmitted from a communication 

partner entity to the commiinication device being 
filtered out by a router. 

Figure 2 : a communication device and a communication partner 
entity in a communication relationship, with the 
15 useful data sent from the communication partner 

entity to the communication device being filtered 
out in the communication device and discarded. 

Both Figures show a communication device IVR (IVR: Interactive 
Voice Response) and a communication partner entity KPI which 

20 exchange useful data with each other via a bidirectional 

connection by means of the RTP protocol. These connections are 
controlled or checked by means of the RTCP protocpl. A router 
R is shown in Figure 1 which filters out with the aid of a 
filter F useful data transmitted to the communication device 

25 IVR, so that this data does not reach the communication device 
IVR. In Figure 2 this filter function is undertaken by the 
communication device IVR itself which filters out useful data 
transmitted from the communication partner entity KPI. with the 
aid of a filter F and discards it, so that said data does not 

30 have to be processed by higher protocol layers. 
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The communication device IVR is for example a software-based 
VoIP (VoIP: Voice over IP) voice response system based on the 
RTP and the RTCP protocol. 

An example is described below for a voice response system 
5 showing how it is possible to work with unidirectional 

channels instead of with bidirectionally operated RTP/RTCP 
channels • 

In the first example corresponding to Fig. 1 an upstream 
router discards the RTP packets in the direction of the voice 
10 response system, so that despite bidirectional through 
connection, no RTP load is imposed on the voice response 
system. 

In the case in which the useful data is handled in the voice 
response system (example corresponding to Fig. 2) the Call 

15 Controller controlling the call or the remote end point 

switches a symmetrical RTP flow through the IP network to the 
voice response system. A static filter is created above the IP 
stack, i.e. the IP protocol stack in the voice response 
system, which detects and discards all IP packets leading to 

20 the voice response system transmitted by means of the RTP 
protocol on the basis of the UDP (user datagram protocol) 
ports used by these protocols. The higher protocol layers 
which would have had to execute the tasks for these packets 
requiring more computing time therefore no longer have any 

25 load imposed on them and only have to handle outgoing data 
flows . 

Since in a software-based voice response system a very high 
proportion of the performance is expended in handling RTP 
protocol sequences, the f reed-up computing time budget can now 
30 be used for example for handling further voice response ports. 
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RTCP sender reports are sent out in the way provided for in 
RFC 1889 (RFC: request for comments). The standard already 
provides for these to be sent out relatively infrequently so 
that no major outlay in computing time is required. Thus the 
5 filter can forward RTCP packets to the RTCP protocol stack of 
the voice response system. 

In accordance with a development of the subject of the 
application the correct functioning of a bidirectional 
connection can be simulated at the level of the RTCP protocol. 

10 The RTCP protocol provides for the optional sending out of 
what are known as Receiver Reports from the voice response 
system to the remote user. Since in the exemplary embodiment a 
bearer or useful data flow is physically switched by the IP 
network, an attempt can be made to evaluate the voice flows or 

15 Voice Activity messages picked up by the remote microphone and 
transmitted via the communication partner entity to simulate 
to the remote user or to its bearer treatment a duplex dream, 
i.e. a bidirectional connection. 

So that the aim of reducing costs which is achieved by 
20 exemplary embodiment 1 is not counteracted, it makes sense to 
dispense with continuous calculation of the RTCP statistics 
based on all received RTP packets. The following approaches to 
solutions for reducing the effort of calculating the RTCP 
statistics can be adopted: 

25 a) Sending out a default Reception Report 

Since a voice response or distribution system described here 
is not dependent on the quality of the flow received, 
experience shows that acceptable default values can be entered 
in the report. If a network operator is to evaluate or 
30 interpret these, he must be aware of the fact that 

specifically these reports are not meaningful merely within 
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the framework of the definition of the default values. This 
ensures that the remote bearer treatment does not initiate any 
undesired counter-measures (e.g. reduces the send rate or 
generates error reports) . The Reception Report can contain the 
5 following parameters (in accordance with RFC 1889) : 

• SSRC (Synchronization source) of the sending source (can be 
determined from any received RTF packets, e.g. by means of 
an RTF sniffer or filter, which at least evaluates a number 
of packets at the beginning of the call/the session or is 
determined from the last received emitter report) 

• Lost Fraction : 256 is entered here, which corresponds to 
an ideal reception. 

• Cumulated number of lost packages: 0 or a very low value is 
entered here. 

• Highest received sequence number: The nximber of Sequence 
Number Cycles and the Highest Sequence Number Received is 
determined from a rounding of an algorithmic calculation 
from 

the time since the last Reception Report (alternately 
20 the beginning of the bearer through -connect ion can be used 

as a basis) 

the Codec Type and its bandwidth and 
the packetization sizes used (results of the Codec 
Negotiation) 

25 by means of the RTF packet number to be expected. These 

parameters are stable for voice response systems for each 
call/session and therefore this type of 
calculation/sequence of divisions is possible. 
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30 



Interarrival Jitter: a non-suspect value which corresponds 
to 1 ms is entered here. 

Last (arrived) SR: The time stamp of the last send report 
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is transferred from the RTCP statistics function for Sender 
Reports . 

• Delay since last (arrived) SR: The delay entered in the 
last send report is transferred from the RTCP statistics 
5 function for Sender Reports. 

b) Reduction of the number of RTP packets which have to be 
processed by the RTCP statistics function. 

Checked via a suitable time-controlled dynamic filter above 
the IP stack (which is sensitive to RTP port addresses) , the 
10 RTCP statistics function is only presented with RTP packets 

over a restricted period of time (e.g. the duration of a voice 
response call), e.g. over a number of equally-distributed 100 
ms intervals of the voice response call which lasts an average 
of 10 seconds. The RTCP ports are in principle open here. 

15 Essentially commercial RTCP statistics can be reused here 
which feign a longer measurement than has actually taken 
place. The parameter "Highest Received Sequence Number" must 
however be approximated as under a) . For the " Interarrival 
Jitter and Lost Fraction" parameters on the other hand the 

20 values generated from the 100 ms measurement can be entered as 
the "real" measured values in the Reception Report. The 
parameter "Cumulated number of lost packages" must also be 
extrapolated . 

If for example intervals lasting 1 second are used as the 
25 basis for sending out the Reception Reports and only 100 ms is 
measured in them in each case, the value to be sent would have 
to be multiplied by a factor of 10. An equal distribution of 
packet losses over the duration of the call is assumed here. 



